1. Field of the Invention
The present invention relates to computer programming, and deals more particularly with techniques for improving systems that support multiple levels of security (e.g., multiple classifications such as “top secret”, “secret”, and so forth) such that those systems do not need to explicitly specify the security level on each data packet they transmit.
2. Description of the Related Art
Governmental agencies and other entities often assign security classifications to data, in order to control access to that data. Security classifications used in the U.S. Department of Defense, for example, include “top secret” and “secret”. A corporation might use security classifications such as “confidential” and “internal use only”. Typically, these security classifications have a hierarchical structure, so that a user or process having access to a particular classification also has access to less-sensitive classifications. Using the governmental example, a user with “top secret” clearance is typically allowed to access data having this classification and also data having the less-sensitive “secret” classification. In addition to controlling access to data using security classifications, access to application programs may also be restricted using classifications.
When security-sensitive information must be transmitted over a communications network, it is necessary to ensure that the security classification of that data is enforced, allowing only authorized users/processes to receive security-sensitive information. Similarly, it is necessary to ensure that only authorized users (including human users and programmatic processes) are permitted to access applications. Systems are known in the art that provide various types of access restrictions for data and for applications. (Hereinafter, references to controlling access to data/information or to controlling access to applications are intended to be synonymous.)
One technique for controlling access is based on the access privileges of individual users, where those access rights are established on a per-user-session basis. For example, when a user logs in to an application, he may be required to provide a user identifier and password. The user-provided values can then be used to consult a stored repository of user access privileges. The privileges for this user can then be used to control what type of information the user can access during the current user session. Typically, the values in such repositories are maintained by a person such as a systems administrator or security administrator.
Additional or different information might be used to determine a user's access privileges. For example, in addition to the user identifier and password, a device identifier of the device from which the user logged in might be used. This technique may be especially useful if stored information exists about physical locations of particular devices, where the physical location is important in determining the user's current access privileges. A user “Bob”, for example, might be authorized to view data classified as “confidential”, provided he is using his office workstation. If he is using his portable computer in a public place, on the other hand, he might only be authorized to view data that is considered “unclassified”. Or, if sufficient physical security restrictions are in place, then access privileges might be determined solely on the basis of the device identifier (or its network address) of a user's device. For example, users might be required to establish their identity using employee badges or biometric information before being allowed to enter a restricted area, where that restricted area includes computer workstations for use by anyone who enters the area.
A particular back-end system or server may be supporting many user sessions concurrently. The term “multi-level security” (“MLS”) system is used to refer to systems that support user sessions having more than one security classification. For example, a document server at a government agency might receive and answer requests for a wide variety of stored documents, and this server may then be required to send data to requesters having various access privileges. Thus, this MLS system must ensure that the appropriate security semantics are enforced for each user session. In contrast, the term “single-level security” (“SLS”) system is used herein to refer to systems that support user sessions that all have a single (identical) security classification. As an example of an SLS system, a document server for public use might receive and answer requests only for unclassified information.
In some cases, access controls in SLS systems are hard-coded, and thus no log-on checking or authorization process is needed. MLS systems, on the other hand, require some type of authorization to determine which security classification is appropriate for each user session.
Maintaining proper access controls is made more difficult if the server or back-end MLS system needs to contact another system. For example, the application with which a user is communicating may trigger remote invocation of another process, or may exchange data with another process. In such cases, it is necessary to ensure that the user's access privileges are still enforced. If the target system is an SLS system, prior art techniques preserve the security semantics of the user session through use of configuration data that specifies, on a per-SLS basis, the security classification that is permissible for communicating with that target SLS system. If the configured classification level is the level needed by the MLS system, then the communication can proceed. (Because of the hierarchical nature of security classifications, the communication may, in some cases, be allowed to proceed if the configuration data indicates that the target SLS system supports a higher-level classification.) However, if the MLS system needs a classification level higher than what this target SLS system provides, then the communication cannot proceed. Typically, the configuration information identifies each permissible target SLS system by its Internet Protocol, or “IP”, address. Or, a range of IP addresses may be used to identify a group of SLS systems having the same security classification.
Prior art systems do not use this configuration data approach when an MLS system is communicating with another MLS system, however, because the IP address of the target MLS system would be ambiguous (i.e., it would not uniquely identify a classification level at the target system). Instead, prior art systems use a technique known in the art as “packet tagging”, whereby each transmitted packet is tagged with information indicating the security classification of that packet. In this manner, one MLS system can exchange data of multiple security classifications with another (target) MLS system, and each system can distinguish among the data packets for the various classifications. The packet tagging comprises appending a particular (variable-length) bit pattern to the header of each outbound packet, where the bit pattern conveys the security classification of the transmitted data. Thus, if MLS system “A” and MLS system “B” exchange data for a number of different security classifications, the classification for each inbound packet can be determined by inspecting the appended bit pattern in the packet header. (The receiving MLS system can then determine, for example, whether it should allow this inbound data packet to pass on to its destination.)
While these prior art packet tagging techniques are functionally sufficient, they have a number of drawbacks. First, packet tagging is computationally expensive. That is, the sender must determine the correct bit pattern to add to each packet, and then modify each packet header to include this bit pattern; the receiver must inspect each incoming packet for its bit pattern, and then compare that bit pattern to a previously-stored association of bit patterns to security classifications. A second drawback is that a significant amount of administrative overhead is required to support packet tagging: typically, the bit patterns must be registered to avoid inadvertent collisions, and these registered patterns must be defined for each supporting MLS system. An additional drawback of existing packet tagging techniques is that many are proprietary or vendor-specific. As a result, interoperability among MLS systems is limited. As yet another drawback, MLS systems that communicate with SLS systems as well as MLS systems must provide “dual path” processing. That is, because packets destined for SLS systems do not use packet tagging, an MLS system needs one set of logic for enforcing the security semantics of outbound packets destined for an SLS system, and a different set of logic when the outbound packets are destined for an MLS system. Similarly, a receiving MLS system needs one set of logic for inspecting packets that have packet tags, and another set of logic for inspecting packets that do not.
Furthermore, the requirement to process bit patterns for packet tagging is not limited to the endpoint MLS systems: each intermediary (such as routers, bridges, and firewalls) in the network path must also understand the packet tags and must enforce the semantics of the security classification based on the contents of those bit patterns, on a per-packet basis. To support packets with packet tags in their headers, special versions of these intermediaries are required. (When transmitting packets to and from SLS systems, in contrast, standard intermediary systems that base their route selection and permission decisions on standard packet headers can be used.)
These prior art drawbacks increase the cost of supporting multiple security classifications and also increase response time to users.
Accordingly, what is needed are improved techniques for supporting multi-level security, and in particular, for supporting communication between MLS systems.